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REMARKS/ARGUMENTS 



Reconsideration of this application is respectfully requested in view of the 
foregoing amendments and discussion presented herein. 

1. Telephone Discussion of January 6, 2006 . 

The Applicant expresses appreciation for the telephonic interview of January 6, 
2006 with the Examiner. During that discussion the independent claims were discussed 
and more particularly changes which may advance the case. 

The amendments herein follow that discussion to clarify the claim elements so 
that they are properly distinguished from how connections are established and torn 
down conventionally, such as described in the Reisman reference (US Publ. 
2003/0229900). 

2. Rejection of Claims 1-35 under 35 U.S.C. § 102(e) . 

Claims 1-35 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
Reisman et al. (U.S. Published Application No. 2003/0229900). 

After carefully considering the grounds for rejection, the Applicant responds as 
follows. The response discusses the shortcomings of the rejection with regard to the 
pending claims and then further in relation to the present amendments of those claims 
which bring out aspects of the claims with more particularity and in keeping with the 
discussion with the Examiner on January 6, 2006. 

Claims 1, 14, 26 and 35 are the independent claims in this application which 
generally recite streaming data over a digital packet-based communication link. Each 
of these claims recites an apparatus or method wherein a stream format or stream 
source for the streaming content is changed without breaking an established protocol 
connection, and in particular the transport portion of that protocol. The claim 
amendments more clearly bring out that the stream portion of the protocol can change 
in response to different sources or formats while the transport portion is retained. 
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DIFFERENT OBJECTS AND OPERATING PRINCIPLES 

The object of the Reisman reference is generally found in the title, "Method and 
Apparatus For Browsing Using Multiple Coordinated Device Sets". The abstract of 
Reisman describes how the system will "allow a user and/or an author to control what 
resources are presented on which device sets (whether they are integrated or not), and 
provide for coordinating browsing activities to enable such a user interface to be 
employed across multiple independent systems". It appears that the system of 
Reisman basically allows routing streams to different devices in a home entertainment 
system, or similar, thus allowing the user to execute browsing functions. 

Paragraph [0027] of Reisman makes a succinct statement about what is being 
sought, as follows. "Providing the desired flexibility can be viewed in terms of three 
interrelated issues, one of structuring an effective and flexible multimachine user 
interface (MMUI) for browsing by a user, one of providing methods (such as markup) for 
the resource creator/author/producer to aid in exploiting that MMUI, and one of 
implementing such an interface on a wide range of hardware and software, including 
systems for which such usage may not be a primary mission (including both new 
systems and legacy systems). " 

The operating principles of Reisman are involved with the integration of TV- 
centric and computer-centric media (paragraph [0004] of Reisman), and more 
particularly the integration of browsing with multiple device sets (bottom of paragraph 
[0008], and paragraph [0010]). The only discussions of establishing communication 
links in Reisman provide for establishing communication connections, of various 
protocols, in a conventional manner. 

Reisman utilizes conventional communication protocols to implement an MMUI 
so that browsing can be performed across sets within an environment, such as a home 
network. Reisman does not, however, teach an apparatus or method wherein a stream 
format or stream source for the streaming content is selected without breaking an 
established protocol connection as recited in the Applicant's claims. 
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NOT ALL CLAIM LIMITATIONS TAUGHT BY REFERENCE 

The concept that a single system, or multiple system for that matter, can share 
the same connections is not related to that which is described in the instant application, 
and in particular the claims therein. Separate devices of necessity utilize separate 
software and protocol stacks, ergo it would not be possible to maintain a logical 
connection over a physical communication medium when changing the source from one 
device to the other. Even supporting multiple connections on a single device in 
Reisman there is no means disclosed for performing switching of sources or formats 
within the low level communication programming, only mechanisms for performing 
conventional switching in which a new connection must be established to change either 
format or source. This is not at all surprising as only conventional transport 
mechanisms are described by Reisman. 

There is no teaching whatsoever within the Reisman reference which can be 
relied upon for considering anything aside from conventional communication transport 
mechanisms. Reisman does not teach an apparatus or method wherein a stream 
format or stream source for the streaming content is selected without breaking an 
established protocol connection as recited in the Applicant's claims. There is no 
teaching within Reisman of dividing up a protocol stack and treating portions differently, 
such as the stream and transport portions, as described within the instant application. 

Furthermore, the switching means of Reisman does not utilize any techniques 
that anticipate the mechanism of low level source or format switching taught within the 
instant application. Nothing has been brought out by the Examiner referencing such an 
aspect in the Reisman reference, while Applicant was also similarly unable to find any 
such elements taught by Reisman. In contrast to the instant application, Reisman 
utilizes conventional stream switching, wherein communications are established, such 
as a communication link wherein the software comprises a full protocol stack 
maintained between a source and destination. 
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Reisman simply does not disclose any mechanisms for maintaining a connection 
intact with portions of the protocol stack, such as the transport portion, still in operation 
while supporting a switch of format or source. Reisman does not teach an apparatus 
or method wherein a stream format or stream source for the streaming content is 
selected without breaking an established protocol connection as recited in the 
Applicant's claims. But then that is not the object of the Reisman reference, nor in 
keeping with the principles of operation of the Reisman reference. 

It is well settled that, in order for a rejection under 35 USC 102 to be properly 
made, the cited reference must teach all of the elements of the rejected claim. In the 
case of the Applicant's rejected claims, the rejection is improper because Reisman 
does not provide any teaching which comports to changing formats without establishing 
a new logical connection (not to be confused with physical connectivity). Therefore, a 
prima facie case of anticipation has not been made out. 

AMENDMENTS FURTHER DISTINGUISH FROM REFERENCE 

It has been shown above that Reisman does not anticipate the pending claims of 
the instant application. It should also be noted that the amendments having been made 
to the claims, even further distinguish over the relied-upon reference. 

The independent claims have been amended to address how the portions of the 
protocol, specifically stream portion and transport section, are treated independently. 
The ability to change the format or source of a digital video stream, without changing 
the transport portion, is fully described. Reisman, by contrast, does not even describe 
any internal aspects of the communication protocols - as had been said earlier these 
are treated conventionally by Reisman. 

Turning to specifics for each independent claim, the Examiner's grounds for 
rejection are improper for the following additional reasons. 

(a) Claim 1 . In support of the rejection of Claim 1 , the Examiner has equated 
the preamble of Claim 1 to the system of Reisman in relation to Figs. 1, 2A and 2B and 
Paragraph 98. However, Reisman clearly does not describe an apparatus for changing 
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the format or source over a digital packet-based communications link without breaking 
the communications link. With regard to the switching function, it is readily apparent 
that Reisman utilizes conventional switching which requires that the traffic stream be 
broken and communication reestablished with the new source (or format); there are no 
teachings from Reisman that indicate otherwise. There is no discussion in Reisman at 
all about implementing format changes or switching within the low level stream 
communication programming. Paragraph [0051] is typical of how communication links 
are discussed in Reisman: "A user session may be local to the user system or may 
involve one or more "communications sessions" with remote server or peer systems, 
where such communications sessions may be defined in accord with a communications 
protocol." There is no discussion of any handling portions of the protocol stack in 
different ways, and more particularly nothing taught by Reisman that has any relation to 
maintaining the transport portion of a protocol stack while changing the source or 
format of the stream portion. 

It should be noted that the instant application primarily addresses connectivity at 
the software level, whereas Reisman addresses the use of physical connections and 
the session layers running on them, which are constructed and dropped conventionally. 
According to conventional communication link operation, a communication link is 
broken as a prerequisite to running a different program, changing source, or the 
changing of the streaming format. The new connection can then be established with 
any desired different source configuration and/or format. But conventionally there is no 
mechanism for making a fast change in source or format because the software layers of 
the protocol must always be torn down before a new connection is made having 
different source or format. 

By contrast to this the claims teach changing source or format "without breaking 
communications link" and describes aspects of this by "changing the stream portion of 
the protocol without changing the transport portion of the protocol." 

Figure 1 of Reisman shows physical connections between a TV, a PC and a 
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PDA/Phone with network connectivity and a local storage device. The associated text 
describes this (top portion of paragraph 0098] as "A number of typically independent 
systems are represented (having associated device sets not shown here in detail), 
including TV or ITV system 130, PC 140, and PDA and/or phone 150, and the like." 

Figure 2A and 2B of Reisman illustrate controllers having multiple input 
connections which can be selected. None of these illustrations provide any 
teaching or indication of changing formats or source within established 
connections, without breaking the connection. 

Examiner refers to paragraphs [0086] - [0087] within Reisman being indicative 
"for communication network protocols including logical path and physical 
communications path". There is no dispute that passing digital data between pieces of 
electronic hardware requires establishing both logical and physical communications 
path. However, this is not the issue being addressed. Claim 1 teaches separating the 
transport portion of the protocol within the logical layer, from the streaming portion of 
the protocol within the logical layer. There is no discussion of this nature within the 
relied-upon section, or that has been found at large in the Reisman reference. 

The Examiner also refers to paragraph [0098] of Reisman as support for the 
rejection - the later portion of paragraph [0098] is as follows: "These systems may 
connect to each other and the outside world via a home network or LAN (local area 
network) or hub 128, which may use wired and/or wireless technology. Auxiliary 
services may also be provided by a home gateway server, which may be combined with 
the LAN, STB, PC, or other device capable of acting as a server, and with other service 
components. External connections may be made directly from a single system, as 
shown for cable 122 connecting to the TV (STB), but may preferably be connected to a 
home network to facilitate shared use by multiple systems, as shown for the connection 
to the Internet 124, and connection to wireless network 126 (which could also be an 
Internet connection, such as using Mobile IP). These external connections provide 
access to various servers and other sources for a variety of sources of content and 
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connectivity 110, which may include broadcast, satellite, and cable TV, video on 
demand, IPTV, streaming media, Web content, wireless portals, transaction servers, 
and the like." 

The above portion of Reisman relied upon by the Examiner only indicates that 
communications can be switched between different sets and can support different 
streaming formats, both aspects of which are well established. 

The Examiner, however, erroneously contends that Reisman provides support 
for "allowing the format or source of a digital video stream to change without breaking 
the communications link to the video display device", to which the Examiner directs 
attention to paragraph [0100] and [0122]. The Examiner errs here in not disclosing 
what portions of these paragraphs supposedly equate to the claimed element. 
Applicant finds no teaching whatsoever in these pages which comport to this aspect of 
the instant application. 

Nothing is found in either paragraph [0100] or [0122] to provide support for any 
such teaching within Reisman of changing source or format without breaking the 
communications link. These paragraphs serve only to indicate that a device can 
support multiple device sets. There is not even description within the Reisman 
reference about a source control library, streaming library, or equivalents, as discussed 
with regard to Applicant's FIG. 1 A - 1 B. It should be readily recognized that unless at 
least a portion of the same communication streaming routines continue to run, the 
connection would be dropped. There is nothing taught by Reisman of a means for 
switching streaming video protocol formats without breaking the communications link. 

As described above, one must understand that the "communication link" as 
recited in the Applicant's claims is a logical link herein established between software on 
a first device which is communicating data to software on a second device such as over 
a network; NOT a physical link such as would be 'broken' by cutting it with a pair of wire 
cutters. 
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FIG. 1 A - 1 B of the instant application show clearly how the format or source of 
video stream is changed without breaking the communications link. Applicant's 
invention illustrates the source control module 12 with programming for a source 
selection routing module 28 for changing source inputs and a streaming controller 14 
for changing the output formats between multiple streaming protocols in a streaming 
library 16 (e.g., RTSP/RTP 44, HTTP 46, and UDP 48). 

Although Claim 1 is clearly not anticipated by the reference, the Applicant has 
amended Claim 1, to further distinguish what is meant by "without breaking the 
communications link!' by describing the streaming portion and transport portions of the 
protocol, and the differential treatment thereof, specifically: 

" establishing a connection between said video server and video display devices 
based on a protocol having a transport portion and a stream portion, 

changing the format or source of a digital video stream to chongo by changing 
the stream portion of the protocol without changing the transport portion of the protocol: 

wherein stream format or source is changed without breaking the 
communications link to the video display device". 

It is well settled that for anticipation under 35 USC 102, the anticipating 
reference must show all the elements of the claim. The Reisman reference cannot be 
equated to the recited aspects of Claim 1 , wherein Reisman can not be considered to 
anticipate the teachings of the instant application as recited in Claim 1. 

Therefore, as Reisman does not anticipate Claim 1 , the Applicant respectfully 
requests that the rejection of Claim 1, and the claims which depend therefrom, be 
withdrawn. 

Claim 14 . Independent Claim 14 describes an apparatus for accommodating a 
change of digital streaming formats or sources in a video server system. 

The rejection indicates that Reisman includes a "source control library" but does 
not indicate where this is found. The only library mentioned by the Examiner is that 
"library for management" mentioned with regard to Claim 2. 
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However, a close reading of Reisman failed to locate the term "source control 
library" or anything which comports to a "source control library" as that term would be 
generally understood in the art. Furthermore, the ONLY mention of library found in the 
relied upon art is a "media asset management/library/archive" as found in paragraph 
[0214]; and "might include services as an entertainment portal, EPG, DVR-style library 
or archive manager" as recited in paragraph [0356]. It is obvious that neither of these 
relate to programmatic elements which can be selectively executed for changing the 
source or communication protocol aspects within the streaming communication. 

The problem with the support for the rejection still remains that Reisman does 
not describe any teachings whatsoever with regard to making a video source or video 
format change without changing the connection. Reisman DOES NOT EVEN disclose 
any implementation details for a streaming controller, and especially does not disclose 
a streaming controller with multiple streaming modules from a streaming library which 
allow changing the stream source or format without changing the connection. 
Consequently, since Reisman does not disclose any implementation details about new 
transport mechanisms it necessarily can be viewed as utilizing existing transport 
techniques. 

The novelty in Reisman is not in the low level handling of streaming traffic. 
Reisman operates according to conventional streaming traffic in a manner described in 
the background of the instant application at paragraph [0007]: " Current practice 
requires the entire video content stream (protocols, software modules, and/or the 
"stacks") to be torn down and rebuilt whenever source selection changes" No 
teachings have been shown from Reisman which disclose any low level stream 
processing which is contrary to conventional stream processing. The bulk of Reisman 
embodiments describe multiple devices, which by definition would have their own 
protocol stack and therein could not perform source or format changing without 
breaking the connection. 
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The amendments to Claim 14 bring out these differences with greater clarity. 
Specifically, the element of "video stream controller" is added to the claim which is 
"configured for establishing a connection based on a protocol having a transport portion 
and a stream portion". Aspects of the source control library and streaming library are 
further recited as "configured for changing the format or source of a digital video stream 
by changing the stream portion of the protocol without changing the transport portion of 
the protocot\ While the streaming library is now said to be "configured for supporting 
the transport portion of the protocof\ There is nothing which remotely comports to 
these aspects within the Reisman reference. 

The reference relied upon under 35 USC 102 does not teach all the elements of 
Claim 14 and as a result cannot be considered as an anticipatory reference. 

Therefore, as Reisman does not anticipate Claim 14, the Applicant respectfully 
requests that the rejection of Claim 14, and the claims which depend therefrom, be. 
withdrawn. 

Claim 26 . Independent Claim 26 recites a method for managing video streams 
provided by a home video server. 

One clear shortcoming with the rejection of Claim 26 is that the step of 
"maintaining the streaming protocol connection with the network display terminal when 
a second stream source is selected", does not comport to anything described within the 
Reisman reference. Reisman does not even provide any low level communications 
programming into which this aspect of Applicant's invention COULD be implemented. 
As described with regard to Claim 1 and Claim 14, the sections of Reisman relied upon 
only disclose conventional forms of switching and format changes which require 
establishing a new connection (logical not physical connection). 

Claim 26 also clearly describes low level communication steps including a 
packetizing step, which also is not described in Reisman. This is not surprising as 
Reisman does not deal with the separate portions of the protocol stack. Examiner 
refers to paragraph [0600] of Reisman for support of the packetizing step, however, this 
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paragraph only teaches that the stream can be communicated with any format or 
protocol, and that IP packets can be sent through at least one of the protocols. This is 
not equivalent to a packetizing step for the first source within the set of low level 
communication steps. 

There is no low level communications programming described within Reisman 
and more particularly no selection of a streaming protocol from a library of streaming 
protocols (see paragraph [0015] of instant application). Not surprisingly, Reisman 
describes nothing for maintaining a connection when a second stream source, or 
format, is selected. 

Reisman provides no teaching which can be equated to "preserving the transport 
portion of the streaming connection ". In addition Claim 26 was amended to add the 
aspect of selectively changing transport stream format so that this aspect, which is 
recited in Claim 1 and Claim 14, is also recited in method Claim 26. 

Considering the above, it will be recognized that the Reisman reference relied 
upon under 35 USC 102 does not teach all the elements of Applicant's Claim 26 and 
thus cannot be considered to anticipate Claim 26 of the instant application. 

Although Claim 26 is clearly not anticipated by the reference, Applicant has 
amended Claim 26 to include how the transport portion and streaming portions are 
handled differently. And specifically how the transport portion is maintained while the 
streaming portion can be changed as to source and/or format. 

Therefore, as Reisman does not anticipate Claim 26, the Applicant respectfully 
requests that the rejection of Claim 26, and the claims which depend therefrom, be 
withdrawn. 

Claim 35 . Independent Claim 35 describes the elements within a home video 
server system. 

Examiner has rejected Claim 35 "for the reasons given in the scope of claims 1- 
13", However, as has been discussed there is clearly no teaching within the relied upon 
Reisman reference for changing source or format without breaking the connection, or in 
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reference to Claim 35 Reisman does not disclose "means for preserving a transport 
portion of the streaming protocol connection.. 

The present invention provides switching and format changing aspects within the 
stream portion of the protocol, while maintaining the transport functionality; therein 
allowing source and format switching without breaking the logical connection and 
without the need of reestablishing an entire connection whenever a different source or 
different format is to be used, as is performed conventionally as in Reisman. The 
importance of this aspect is clearly stated in the instant application, such as at 
paragraph [0034]: "It is to be understood that the present invention separates the 
resources that comprise the stream source from the resources that maintain the 
transport connection to the client display. This arrangement allows for the format and 
resources that make up a content stream to change without breaking the connection to 
a client display device, e.g., an NDT 20. The connection to the NDT 20 can be 
maintained independent of the resources required to produce the stream or the format 
of the stream itself. It is to be further understood that the present invention creates a 
separately managed and sustained transport connection to each of the clients of the 
home media server 50. This connection can be maintained while the source formats 
and resources needed to package data for the client can change." 

Since Reisman does not disclose any means for maintaining an established 
streaming protocol connection when the stream or format changes it cannot therefore 
anticipate Claim 35. 

Although Claim 35 is clearly not anticipated by the reference, Applicant has 
amended Claim 35 to clarify the streaming protocol as having a streaming portion and a 
transport portion. Wherein it can be seen that the format and source changes effect 
the streaming portion and not the transport portion. 

Therefore, as Reisman does not anticipate Claim 35, Applicant respectfully 
requests that the rejection of Claim 35 be withdrawn. 
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Claims 2-13, 15-25 and 27-34 . Dependent Claims 2-13, 15-25 and 27-34 should 
be considered a fortiori allowable in view of the patentability of their respective base 
claims. 

Applicant takes this opportunity, however, to point out a number of errors that 
have arisen with regard to the support provided for these rejections. 

Claim 2. Dependent Claim 2 describes the means for changing the format or 
source of a digital video stream without breaking the digital packet based 
communications link to the video display. Within this means a source control library 
and streaming library are connected by a source controller. Examiner has improperly 
equated this to teachings within Reisman which also happen to contain the word 
"library". As the library elements found in Reisman are content databases or content 
management oriented (a "media asset management/library/archive" as found in 
paragraph [0214]; and "might include services as an entertainment portal, EPG, DVR- 
style library or archive manager" as recited in paragraph [0356]) and do not contain low 
level transport related programming and more particularly programming specific to 
performing the changing of source or format without breaking the connection, they have 
no negative bearing on patentability of the instant application. 

Claims 3-13, 15-25 and 27-34. Without going into great detail, the majority of the 
dependent claims have been rejected based on a Reisman, although there is a lack of 
teaching within Reisman. 

Therefore, Applicant respectfully requests that the rejections of these dependent 
claims be immediately withdrawn. 
3. Claims 1-35 are nonobvious . 

Nor would the subject matter of Claims 1-35 be obvious to a person having 
ordinary skill in the art in view of Reisman. Nothing in the Reisman reference suggests, 
teaches or provides motivation for creating a means for changing sources and formats 
by changing a streaming portion of the protocol without changing the transport portion 
of the protocol. This explains the basis is why the formats and sources can be changed 
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without breaking the communications link and while preserving the transport portion of 
the streaming connection. Applicant describes low level communication programming 
for performing this means as recited in the claims. Reisman does not even disclose low 
level communications transport mechanisms, but uses existing mechanisms in creating 
a higher level construction, specifically an MMUI. Nor is there any suggestion, teaching 
or motivation which could be derived from that reference which would cause a person 
having ordinary skill in the art to so modify Reisman's MMUI to perform these low level 
packet communication aspects. There does not even exist within the Reisman 
reference teachings of any such low level transport mechanisms upon which 
combinations can be constructed toward obviating Applicant's claims. 

Therefore, since there is no suggestion, teaching or motivation which can be 
found in the reference from which a person having ordinary skill in the art would find it 
obvious to modify the MMUI of Reisman to correspond to that described in the 
Applicant's claims, Claims 1-35 recite structure, and/or steps which are patentable over 
the cited references for purposes of 35 U.S.C. § 103. 
4. Traversal of Rejection of Claim 1 and 35; In re Donaldson . 

The Applicant respectfully traverses the grounds for rejection, and cites In re 
Donaldson, 16 F.3d 1 189, 1 193 (Fed. Cir. 1994)(en banc) as the basis for the traversal. 
Claims 1 and 35 are written in means plus function form pursuant to 35 U.S.C. §112, 
sixth paragraph, and therefore, must be interpreted during examination under In re 
Donaldson, 

In rejecting Claims 1 and 35, as well as the claims that depend therefrom, the 
Examiner made no specific fact findings as to the scope of equivalents for the means 
plus function elements in the claims. Instead, the Examiner appears to have followed 
the provisions of MPEP § 2183 ("Making a Prima Facie Case of Equivalence"), which 
states: 

If the examiner finds that a prior art element performs the function specified in 
the claim, and is not excluded by any explicit definition provided in the 
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specification for an equivalent, the examiner should infer from that finding that 
the prior art element is an equivalent, and should then conclude that the claimed 
limitation is anticipated by the prior art element. The burden then shifts to 
applicant to show that the element shown in the prior art is not an equivalent of 
the structure ... disclosed in the application. In re Mulder, 716 F.2d 1542, 219 
U.S.P.Q. 189 (Fed. Cir. 1983). No further analysis of equivalents is required of 
the examiner until applicant disagrees with the examiner's conclusion, and 
provides reasons why the prior art element should not be considered an 
equivalent. 

While the Examiner appears to have attempted to follow the provisions of MPEP 
§2183, albeit lacking specificity of functional equivalence in the relied upon reference, 
such provisions are contrary to Federal Circuit law. The Federal Circuit has held that 
an examiner "construing means-plus-function language in a claim must look to the 
specification and interpret that language in light of the corresponding structure 
described therein, and equivalents thereof," In re Donaldson, 16 F.3d 1189, 1193 (Fed. 
Cir. 1994)(en banc), and in so ruling expressly denied that "the PTO is exempt from this 
mandate." ]d. The Federal Circuit added that it was specifically overruling any 
precedent that suggested or held to the contrary. Id. at 1 193-94. In response to the 
PTO's argument that the court's ruling conflicted with the principle that a claim should 
be given its broadest reasonable interpretation during prosecution, the Federal Circuit 
held that the Donaldson decision was setting "a limit on how broadly the PTO may 
construe means-plus-function language under the rubric of 'reasonable interpretation.'" 
]d. at 1 194. In other words, an examiner's claim interpretation is not "reasonable" if it is 
not based on the specification's description of the implementation of the means 
element of the claim. The court then said, "Accordingly, the PTO may not disregard the 
structure disclosed in the specification corresponding to such [means-plus-function] 
language when rendering a patentability determination. " ]d. at 1 195. 
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Here, as in Donaldson, the Examiner is required by statute to look to the 
Applicant's specification and construe the "means" language as referring to 
corresponding means disclosed in the specification and equivalents thereof." See id. at 
1 195. However, the Examiner did not construe the means language of these claims. 
Nor did the Examiner find, on the basis of specific facts of record here, that the means 
disclosed in the Applicant's specification were equivalent to that of the cited references. 
Instead, as prescribed by MPEP §§ 2183-84, the Examiner simply presumed 
equivalence. The presumption methodology used here, which the MPEP prescribes, 
clearly conflicts with the requirements of the Federal Circuit's Donaldson decision. The 
approach taken by the Examiner in this case also conflicts with In re Bond, 931 F.2d 
831 (Fed. Cir. 1990). 

The very point of these cases is that, in this context, limitations from the 
specification control the interpretation of the claim. Under §112, paragraph 6, a 
means-plus-function element of a claim must be construed to mean that which is 
disclosed in the specification and its equivalents. In Donaldson, the Federal Circuit said 
that "our holding does not conflict with the general claim construction principle that 
limitations found only in the specification of a patent or patent application should not be 
imported or read into a claim." In other words, the court was saying that a §1 12, 
paragraph 6 "means" element does not need to be "imported or read into" a 
means-plus-function claim because the specification's limitations and their equivalents 
are already in the claim by virtue of §112, paragraph 6's command. Thus, the Federal 
Circuit said (16 F.3d at 1 195): "What we are dealing with in this case is the construction 
of a limitation already in the claim in the form of a means-plus-function clause and a 
statutory mandate on how that clause must be construed." 

Based on the foregoing, the Applicant respectfully submits that the rejection of 
Claims 1 and 35, as well as the claims that depend therefrom lacks proper foundation 
and that the rejection should be withdrawn. Those claims, each of which include 
means plus function limitations, should have been interpreted in view of the 
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specification as required by In re Donaldson. If those claims had been so interpreted, 
they would have been allowable since the cited references do not anticipate or render 
obvious by way of teaching, suggestion, motivation or incentive, the subject matter 
recited in those claims. 

5. Amendment of Specification. 

Paragraphs [0026], [0029] and [0030] were amended to correct typographical 

errors. 

Paragraph [0032] was amended to correct a block number and add a step that 
was missing in describing the flowchart of FIG. 2. Specifically, what was called out as 
block 106 was actually block 108, to which correction was made. The missing 
description of block 106 was then added to text based directly on the text which is 
found in block 106 of FIG. 2; specifically: " At block 106 a stream module is selected 
based on the selected streaming protocol . 11 

The amendments to the specification do not constitute added material disclosure 
and serve only to correct and clarify the existing disclosure. Applicant apologizes for 
any inconvenience which these errors may have caused the Examiner. 

6. Amendment of Claims 1 . 2, 14, 16, 26 and 35 . 

Claims 1 14, 26 and 35 . These independent claims were amended to clarify 
that the claims are describing the use of a digital packet based communication link 
having a protocol with a streaming portion and transport portion. 

Support for this clarification is found throughout Applicant's specification, 
including paragraphs [0008], [0010], [0011], [0016], [0033], [0034], and so forth. In 
particular the first portion of paragraph [0034] is given as: "It is to be understood that 
the present invention separates the resources that comprise the stream source from the 
resources that maintain the transport connection to the client display. This arrangement 
allows for the format and resources that make up a content stream to change without 
breaking the connection to a client display device, e.g., an NDT 20. The connection to 
the NDT 20 can be maintained independent of the resources required to produce the 
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stream or the format of the stream itself. It is to be further understood that the present 
invention creates a separately managed and sustained transport connection to each of 
the clients of the home media server 50. This connection can be maintained while the 
source formats and resources needed to package data for the client can change." 

Claim 2 . Dependent Claim 2 was amended to include the phrase "digital packet- 
based 1 to provide proper antecedent basis with Claim 1 . 

Claim 16 . Dependent Claim 16 was amended to recite additional element, 
which were noted had been left off from the original claims. In particular: "an analog 
video source from AV equipment or cable" and "a digital video source". 

Support for these aspects is found in the specification, including paragraph 

[0035]: 

"As stated above, in a preferred embodiment, the present invention can be part 
of a home media server system 10 in which a home content server 50 delivers video 
streams to multiple NDTs 20 from a selection of stream sources. These stream sources 
can range from AV equipment plugged into the content server to a hard disk drive of 
recorded content to a cable connection, a satellite receiver or a connection to the 
Internet, as well as others" 

Additional support is also found in the specification, such as at paragraph [0026]: 
"In a preferred embodiment, an Ethernet streaming video source 36 provides an 
Ethernet streaming video signal to the Ethernet streaming video interface 30 which 
converts the Ethernet streaming video signal to a compressed digital video data signal 
and sends the data signal to the SRS module 28. The SRS module 28 can control the 
Ethernet streaming video interface 30 using an Ethernet streaming video control API 
that is sent to the Ethernet streaming video interface 30. As further shown in FIG. 1A - 
1B, a hard disk drive such as an audio/visual hard disk drive (AV HDD) 38 can provide 
a compressed digital video data signal to the PVR/File playback module 32. Preferably, 
the PVR/file playback module 32 sends a compressed digital video data signal to the 
SRS module 28. Operation of the PVR/file playback module 32 can be controlled by a 
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PVR control API sent to the PVR/file playback module 32 by the SRS module 28. It can 
be appreciated that other sources can provide content to the SRS module 28. For 
example, these sources can include an iLink source, a memory stick, an audio/visual 
(AV) source, or any other media source." 
7. Amendments Made Without Prejudice or Estoppel. 

Notwithstanding the amendments made and accompanying traversing remarks 
provided above, Applicant has made these amendments in order to clarify aspects of 
the claims and toward expediting allowance of the currently pending subject matter. 
However, Applicant does not acquiesce in the original ground for rejection with respect 
to the original form of these claims. These amendments have been made without any 
prejudice, waiver, or estoppel, and without forfeiture or dedication to the public, with 
respect to the original subject matter of the claims as originally filed or in their form 
immediately preceding these amendments. Applicants reserve the right to pursue the 
original scope of these claims in the future, such as through continuation practice for 
example. 
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8. Conclusion . 

Based on the foregoing, Applicant respectfully requests that the various grounds 
for rejection in the Office Action be reconsidered and withdrawn with respect to the 
arguments presented herein, and that a Notice of Allowance be issued for the present 
application to pass to issuance. 

In the event any further matters remain at issue with respect to the present 
application, the Applicant respectfully request that the Examiner please contact the 
undersigned below at the telephone number indicated in order to discuss such matter 
prior to the next action on the merits of this application. 




Respectfully submitted, 




.John P. O'Banion, Reg. No. 33,201 
O'BANION & RITCHEY LLP 
400 Capitol Mall, Suite 1550 
Sacramento, CA 95814 
(916) 498-1010 
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